Verifiable trust is a desirable property for computing systems—a user has a fundamental interest in knowing whether a computing platform about to be used (or in use) by the user will behave in a reliable and predictable manner, or will be (or already is) subject to subversion.
Existing trusted platforms typically contain a component at least logically protected from subversion; such platforms have been developed by the companies forming the Trusted Computing Group (TCG)—this body develops specifications in this area and the current TCG specifications are available at http://www.trustedcomputinggroup.org (see, in particular, the Trusted Platform Module Design Principles specification). The implicitly trusted components of a trusted platform (and, in particular, the Trusted Platform Module or ‘TPM’) enable integrity measurements of the platform to be reliably made and stored and subsequently reported as integrity metrics to users (including remote computing entities) wishing to interact with the platform. Such users are then able to determine from the consistency of the measured integrity metrics with known or expected values that the platform is operating as expected.
With the general trend of designing systems that maximize resource sharing (e.g., through virtualization technology), parties that consume these resources increasingly require a means of verifiable trust before deploying information-sensitive content on these systems. This issue is particularly critical for systems that host parties with potentially conflicting interests. A challenge in trust management is to manage trustworthiness in highly dynamic virtualized computer systems. This involves being able to monitor system integrity in an on-going fashion and to report changes in order to reflect the current system state. This is particularly crucial for systems in which system configuration and security policies frequently change and components are allowed to operate in various security modes. Current solutions usually deem such changes as malicious and, for example, require a system reset and restart to be able to re-establish trust. These solutions are either impractical or do not scale as the number of system components increase in a complex computer system.
The trust architecture set out in the TCG specifications mainly addresses the creation of a chain-of-trust in a static manner in which the relevant state of software components is measured once at the time it is loaded. These measurements are stored in so-called Platform Configuration Registers (PCR) of the TPM, and are incremental, that is, a sequence of measurements can be reported in the same PCR by incrementally extending the previous measurement without changing its size, thus enabling virtually infinite number of measurements. This way, the complete execution sequence can be recorded enabling a third-party to verify it at a later phase. This static architecture imposes several limitations on complex dynamic systems in which system configuration and security policies are allowed to change frequently:
The TCG trust architecture does not efficiently handle the situation in which critical (i.e., measured) system components are allowed to change into another form (e.g., through a software update) or adapt to current conditions, or the situation in which system components may function in various operating modes (e.g., with different configurations) to perform operations with varying security needs. In either situation, the TCG specifications takes the conservative approach and deem any such change as potentially malicious and irreversible.